![]() |
Java Database Programming with JDBC
by Pratik Patel Coriolis, The Coriolis Group ISBN: 1576100561 Pub Date: 10/01/96 |
Previous | Table of Contents | Next |
Security is at the top of the list of concerns for people sharing databases on the Internet and large intranets. In this chapter, well have a look at security in Java and how Java/JDBC security relates to database security. Well also have a peek at the new security features planned for Java, which will incorporate encryption and authentication into the JDBC.
The first issue Id like to tackle, and the first one you need to consider, is the security of your actual database server. If you are allowing direct connections to your database server from your Java/JDBC programs, you need to prepare for a number of potential security pitfalls. Although security breaks are few and far between, I advise you to cover all the angles so you dont get caught off-guard.
Information is sent over networks in packets, and packet sniffing happens because a computers network adapter is configured to read all of the packets that are sent over the network, instead of just packets meant for that computer. Therefore, anyone with access to a computer attached to your LAN can check out all transactions as they occur. Of course, a well-managed network and users you can trust are the best methods of preventing an inside job. Unfortunately, you must also consider another possibility: the outside threat. The possibility that someone from outside your LAN might break into a computer inside your LAN is another issue altogether; you must make sure that the other computers on your LAN are properly secured. To prevent such a situation, a firewall is often the best remedy. Though not completely foolproof, it does not allow indiscriminate access to any computers that are behind the firewall from outside. There are several good books on basic Internet security, and this books Website contains a list of URLs that highlight several books on firewalls.
Packet sniffing doesnt necessarily involve only your local network; it can occur on the route the packet takes from the remote client machine somewhere on the Internet to your server machine. Along one of the many hops a packet takes as it travels across the Internet, a hacker who has gained entry into one of these hop points could be monitoring the packets sent to and from your server. Although this is a remote possibility, its still a possibility. One solution is to limit the IP addresses from which connections to the database server can be made. However, IP authorization isnt bulletproof eitherIP spoofing is a workaround for this method. For more information on these basic security issues, please see this books Web site for references to security material.
If you only allow local direct access to your database server via pre-written software, like CGI scripts run from Web pages, youll still find yourself with a possible security hole. Some folks with too much time on their hands take great pleasure in hacking through CGI scripts to seek out unauthorized information. Are you vulnerable to this type of attack? Consider this situation: You have a CGI script that searches a table. The HTML form that gives the CGI its search information uses a field containing a table name; if a hacker realizes that you are directly patching in the table name from the HTML page, it would be easy to modify the CGI parameters to point to a different table. Of course, the easy solution to this scenario is to check in the CGI script that only the table you intend to allow to be queried can be accessed.
For in-house distribution of Java programs that access database servers, many of these security considerations are minimal. But for Internet applications, such as a merchandising applet where a user enters a credit card number to purchase some goods, you not only want to send this data encrypted to the Web server, but you want to protect the actual database server that this sensitive data is stored on.
So how do we deal with these security holes? The most straightforward way is to use a database server that implements secure login encryption. Some database servers do this already, and with the proliferation of Web databases, login encryption is likely to be incorporated into more popular database servers in the future. The other solution, which is more viable, is to use an application server in a three-tier system. First, the Java program uses encryption to send login information to the application server. Then, the application server decodes the information. And finally, the application server sends the decoded information to the database server, which is either running on the same machine or on a machine attached to a secure local network. Well discuss application servers in more detail in Chapter 11.
Another solution involves using the Java Security API, currently under development at Javasoft. This API, which provides classes that perform encryption and authentication, will be a standard part of the Java API and will allow you to use plug-in classes to perform encryption on a remote connection.
As a user, how do you know if the Java applet youre getting is part of a front for an illegitimate business? The Java Commerce API addresses the security issue of determining whether an applet is from a legitimate source by using digital signatures, authorization, and certification. Both the Java Commerce API and Java Security API will likely be incorporated into Web browsers Java interpreters, and will also be linked in heavily with the security features of the Web browser itself. At the time this manuscript was written, however, these APIs were still under construction.
As weve seen, setting up safe connections is quite possible. However, applet security is an entirely different issue. This aspect of security, where an applet that has been downloaded to your computer is running in your Web browser, has been under scrutiny since Java-enabled Web browsers appeared.
Previous | Table of Contents | Next |